Skip to content

Fix typing of SeqLiterals #1166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 18, 2016
Merged

Fix typing of SeqLiterals #1166

merged 4 commits into from
Mar 18, 2016

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Mar 10, 2016

Now it's more like what scalac is doing - unfortunately the previous, far simpler scheme fails in the presence of empty non-variant Java seq literals, as #1136 illustrates.

Fixes #1136.

odersky added 3 commits March 10, 2016 16:46
The field keeps track of the element type. This is necessary
because JavaSeqLiteral is nonvariant and the elements might
be empty, so we cannot always compute the type from the
element types.
The test contained an error that was unvovered by the "Nothing is not Nullable" fix.
@DarkDimius
Copy link
Contributor

@odersky, as current scheme fails only for empty seq literals, instead of going for the old scalac scheme, would you consider this:

case class SeqLiteral[-T >: Untyped] private[ast] (elems: List[Tree[T]])
class EmptySeqLiteral[-T >: Untyped] private[ast] (elems: List[Tree[T]], elemtpt: Tree[T]) extends SeqLiteral(elems)

Only empty SeqLiterals would need to retain the elem type and only TypeAssigner would needs to know of their existance.

@odersky
Copy link
Contributor Author

odersky commented Mar 12, 2016

@DarkDimius It turns out this does not help much, since the element type has to be propagated everywhere in any case.

@DarkDimius
Copy link
Contributor

@odersky, as empty sequences are only created by Typer, couldn't EmptySeqLiteral simply remember the prototype that they were created with?

@odersky
Copy link
Contributor Author

odersky commented Mar 12, 2016

@DarkDimius Adding the second parameter is precisely for remembering the prototype.

odersky added a commit that referenced this pull request Mar 18, 2016
@odersky odersky merged commit e73ef77 into scala:master Mar 18, 2016
@allanrenucci allanrenucci deleted the fix-#1136 branch December 14, 2017 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants